1. Field of Invention
The field of invention relates to computing systems generally, and, more specifically, to an interrupt return instruction with embedded interrupt service functionality.
2. Background
Instruction Execution Pipeline
FIG. 1 shows a high level diagram of a processing core 100 implemented with logic circuitry on a semiconductor chip. The processing core includes a pipeline 101. The pipeline consists of multiple stages each designed to perform a specific step in the multi-step process needed to fully execute a program code instruction. These typically include at least: 1) instruction fetch and decode; 2) data fetch; 3) execution; 4) write-back. The execution stage performs a specific operation identified by an instruction that was fetched and decoded in prior stage(s) (e.g., in step 1) above) upon data identified by the same instruction and fetched in another prior stage (e.g., step 2) above). The data that is operated upon is typically fetched from (general purpose) register storage space 102. New data that is created at the completion of the operation is also typically “written back” to register storage space (e.g., at stage 4) above).
The logic circuitry associated with the execution stage is typically composed of multiple “execution units” or “functional units” 103_1 to 103_N that are each designed to perform its own unique subset of operations (e.g., a first functional unit performs integer math operations, a second functional unit performs floating point instructions, a third functional unit performs load/store operations from/to cache/memory, etc.). The collection of all operations performed by all the functional units corresponds to the “instruction set” supported by the processing core 100.
The IRET Instruction
FIG. 2 pertains to the servicing of an interrupt, fault or exception. Software program code can often be viewed as multiple concurrently active programs and/or processes. Although not a strict requirement, in practice, programs/processes 202 and 203 correspond to different software and/or hardware “threads”. For simplicity, since programs, processes and threads can each be viewed as a consecutive sequence of executed instructions, the term “program” will also be used to refer to a process as well as a thread.
Often, an active program 201 (e.g., a device driver or an application software program) will encounter some kind of problem and report or “throw” an interrupt, fault or exception to an interrupt handler 203 by executing an “interrupt instruction” (INTRPT_INSTR) 202. Here, an interrupt instruction 202 is any portion of program code that invokes an interrupt handler as a consequence of an interrupt, fault or exception. Moreover, any of an interrupt, fault or exception will be referred to as an “interrupt”. An interrupt handler 203 is typically a system program specifically designed to handle interrupts (e.g., an interrupt handler of an Operating System (OS) kernel). Because active program 201 invokes the interrupt handler 203, active program 201 may also be referred to as the invoking program 201.
The functionality of the interrupt instruction 202 typically includes the passing of two items of information to the interrupt handler 203: i) a special code 204 and/or other item(s) of information that identify the specific problem that has been encountered; and, ii) a return address pointer 205 that identifies an address for the next instruction 206 of the invoking program 201 to be executed once the interrupt has been handled.
The interrupt handler 203 “handles” the problem that caused the interrupt to be raised. An initial part of the handling process 203a is to use the special code 204 as a look-up parameter into a lookup table 206 that identifies an initial address for a sub-routine program 203b written to handle the specific problem identified by the code 204. Program flow jumps to this sub-routine 203b and the problem that caused the interrupt is handled. Once the problem that caused the interrupt is handled, an IRET instruction 203c is executed to cause the process flow to jump back or “return” 207 to the invoking program 201. As such, the functionality of the IRET instruction includes referring to return address pointer 205 to cause the desired program flow jump.